home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
HPAVC
/
HPAVC CD-ROM.iso
/
DEVELOP.ZIP
/
USERSYS.DOC
< prev
Wrap
Text File
|
1996-07-23
|
35KB
|
696 lines
WARNING: This document is subject to change at any time. Any changes made
will be indicated by a vertical bar (|) in column 1 of the file.
| Last update: 07/23/96
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
WHAT ARE THE USERS.SYS AND USERS.INF FILES
------------------------------------------
The USERS.INF file is an extension to the USERS file. It is generally
accessed solely by PCBoard software with third party software utilizing
the USERS.SYS file instead.
The USERS.SYS file is a "single source" for everything you need to know
about the caller that is online. It is created by PCBoard - but may be
UPDATED by a door or utility program.
USERS.INF BRIEF OVERVIEW
------------------------
The USERS.INF file layout boasts some pretty high limits that hopefully
will take the software through the next few years without major
modifications. For example, the following capabilities exist within the
file structure:
* A variable number of conferences ranging from 0 to 65495 - with the other
40 conferences being stored in the main USERS file.
* A variable sized PCBoard record which will allow for growth in the future
without causing major upgrade problems with file formats are changed.
* A variable number of installable Third Party Applications (from 0 - 65535)
providing KEYWORD access to the applications and permitting the application
to "piggy back" its user record needs onto the USERS.INF file while
allowing PCBoard software to performance the maintenance on the file.
* Variable sized records for Third Party Applications allowing each Third
Party Application to use up only what it needs - or as much as it needs.
In essence, PCBoard will have the file layout capability for as many as
65,535 conference areas (though the software may lag behind the file
layout's capabilities for some time due to memory constraints as well as
user interface problems - but those can be dealt with later on).
It will also allow Third Party Authors to install their software (using a
PCBSM) into PCBoard's system files - that is, the Third Party Software
could actually store their own information inside of PCBoard's USERS.INF
file by telling PCBoard that they are there and how much file space they
need. This way PCBoard and its utilities would be able to help out with
maintenance of the file such as adding in new records or deleting existing
records, etc.
Additionally, when PCBoard opens a door it will check the name of the
door against the KEYWORD used in the TPA header to determine if the
USERS.SYS file should include a TPA record.
USERS.SYS BRIEF OVERVIEW
------------------------
The USERS.SYS file is the one that DOOR and UTILITY authors are expected to
read and write. It is a "one stop shopping spot" for everything you need
to know about the user that is currently online. The DOOR or UTILITY
author can feel free to update the USERS.SYS file and any changes made to
the user record (whether PCBoard's own user record or the TPA user records
in the file) will be automatically posted to the appropriate files when
PCBoard reloads.
Because the information in the USERS.SYS file is derived from a combination
of the USERS and USERS.INF file - it contains the same flexibility for
growth and capabilities as described above regarding the USERS.INF file.
The file layout itself includes a header record that describes the size of
the PCBoard user record and the name of the TPA and its record size (if
any). The header record should be inspected first to determine how much of
the file should be read in (you may not need to read the whole file - only
that which is necessary for your own operation) and how much should be
updated if you are going to make any changes to the file.
USERS.INF FILE LAYOUT
---------------------
NOTE: it is recommended that people access only the USERS.SYS file and not
touch the USERS.INF leaving that job up to PCBoard. However, in the case
where an application may need to globally modify the records that belong
to it in the USERS.INF file it may be necessary to know a little about the
header record and how to get to the Third Party Application records.
The file layout comes in 4 separate parts. They are:
1) A header describing PCBoard's file allocation requirements
2) A header describing each of the TPA file allocation requirements
3) The PCBoard User Record
4) Each of the TPA extensions to the PCBoard User Record
Knowing the above you can determine the total HEADER size (comprised of
parts 1 and 2 above) by calculating the size of the PCBoard header then
adding to that the size of the application header multiplied by the number
of applications.
Determining the user record size is similarly accomplished by adding the
size of PCBoard's data record together with all of the data records
specified by the application headers.
Examples of the above will be provided down below following the formal file
formats.
USERS.INF RECORD STRUCTURES
---------------------------
typedef struct {
unsigned Version; PCBoard Version Number
unsigned NumOfConf; Number of EXTENDED Conferences Allocated in File
unsigned SizeOfRec; Size of the 'static' PCBoard User Record
long SizeOfConf; Total Size of PCBoard Conference Information
unsigned NumOfApps; Number of Third Party Apps adding onto the record
long TotalRecSize; Total Record Size (PCB and all TPA components)
} hdrtype;
typedef struct {
char Name[15]; Name of Application (NULL terminated)
unsigned Version; Version Number
unsigned SizeOfRec; Size of Application Record information (0-65535)
unsigned SizeOfConfRec; Size of Conference Record information (0-65535)
char KeyWord[9]; Keyword to execute Application (NULL terminated)
long Offset; Offset in User Record where TPA record begins
} apptype;
ACCESSING THE FILE
------------------
Accessing the file comes in two steps. One is in reading the file header
which can be done upon program initialization - and the other is in
locating a specific user record.
Step 1: Read the HEADER record to determine (1) how big the header is
and (2) how big each record is.
To determine how big the header is you multiply the number of
TPA's by the size of the Application Header record and add to
that the size of the main Header record.
Example:
HdrSize = sizeof(hdrtype)+(Hdr.NumOfApps * sizeof(apptype));
The size of each record is stored in the header itself.
Step 2: Using the information gathered in step 1 above it's fairly easy
to get to the actual user record. For example, if you wanted to
read the information in a user record you would use the following
code:
lseek(File,(RecNum-1)*TotalRecSize + HdrSize,SEEK_SET);
In other words, you would calculate the record number minus 1 and
multiply it by the total user record size as determined in step 1
and add to that the size of the header record. Moving the disk
head to this position sets you up to read the PCBoard user record.
If you wanted to skip over the PCBoard component of the user
record then you would simply add the OFFSET of the TPA record into
the equation like this:
lseek(File,(RecNum-1)*TotalRecSize + HdrSize + Offset,SEEK_SET);
RecNum will be a LONG integer stored at offset 385 in the USERS
file (i.e. bytes 385, 386, 387 and 388 comprise the RECNUM which
will be used to access the USERS.INF file).
This file layout and accessing methodology, though somewhat complicated,
gives the following benefits:
- Because the PCBoard data size is determined by a field in the header
it is therefore allowed to GROW at will - that is to say, when
PCBoard needs new fields it can add those fields into the record and
adjust the file format without breaking Third Party Software that is
already coded to read and use the USERS.INF file.
- Because the number of conferences is specified in the header the
sysop will have the ability to grow or shrink his USERS.INF file
according to his needs as he adds or removes conferences.
- Because the header also accounts for Third Party Applications and
their needs it will allow Third Party Authors to more easily install
their software into a PCBoard system and then let PCBoard take care
of adding and removing user records. This also saves storing yet
another file on disk that may be redundant in nature compared to
similar files used by similar Third Party programs.
THE PCBOARD RECORD IN THE USERS.INF FILE
----------------------------------------
It is preferable that Third Party Applications do *not* access the PCBoard
data area within the USERS.INF file if it can be avoided for the the simple
reason that PCBoard may expand on it and access to USERS.SYS is recommended
instead. However, the following information provides details as to how the
PCBoard data record is CURRENTLY formatted:
typedef struct {
char Name[25]; User Name (in case connection to USERS is lost)
long MsgsRead; Number of messages the user has read in PCBoard
long MsgsLeft; Number of messages the user has left in PCBoard
} rectype;
The above is the current format of the STATIC portion of the the PCBoard
record. The size of which is specified in the USERS.INF header field
hdrtype.SizeOfRec.
The conference record is much more difficult to access and cannot be
described by a fixed typedef structure. The following two calculations
are required before you'll be able to read the file:
ConfByteLen = (NumAreas / 8) + ((NumAreas % 8) != 0 ? 1 : 0);
if (ConfByteLen < 5)
ConfByteLen = 5;
ExtConfLen = ConfByteLen - 5;
In the conference record you will then find 5 bit map fields in the following
order:
1) Mail Waiting Flags (length is ConfByteLen bytes long)
2) Conference Sysop Flags (length is ConfByteLen bytes long)
3) Registered In Conference (length is ExtConfLen bytes long)
4) Exp. Conference Registrations (length is ExtConfLen bytes long)
5) Conference Scan Preference (length is ExtConfLen bytes long)
Note that ConfByteLen will always be at least 5. While ExtConfLen can be 0
bytes in length if the number of conferences on the system is 39 or less.
The reason is because fields 3, 4 and 5 are already contained within the
USERS file for conferences 0 thru 39.
Immediately following the above structure are the Last Message Read pointers.
The number of which can be 0 (if 39 conferences or less) or more if there are
conferences beyond 39. Each Last Message Read pointer is a long integer.
A note on the usage of the Registered and Expired Registration flags:
PCBoard will turn the REGISTERED flag off while leaving the EXPIRED
registration flag turned on to indicate that the caller is locked out.
Examples:
Registered Expired PCBoard Shows Explanation
---------- ------- = ------------- -----------
Off Off "" Caller is not registered but
may join if the conference is
public and his security level
permits access.
On Off "R" Caller is registered in this
conference. If he expires then
he can no longer access it
unless it is public and his
security level permits access.
On On = "RX" Caller is always registered.
Off On = "L" Caller is locked out and
cannot join the conference
regardless of whether it is
public or not.
THE PCBOARD SUPPORTED ALLOCATIONS
---------------------------------
PCBoard may actually have more information in the USERS.INF than just the
information shown above. This additional information, called PCBoard
Supported Allocations (PSAs), however, is treated exactly the same as any
Third Party Allocations (TPAs) in the file.
The only difference is that PCBoard and PCBSM directly support the PSAs by
providing access to them instead of merely storing and manipulating them.
For example, the Alias Support PSA holds a caller's alias. If it is
installed, then PCBoard will keep track of the caller's alias and PCBSM will
allow you to see the alias by hitting the F2 function key a couple of times
while in the Users File Editor.
USERS.INF FILE SIZE FORMULA
---------------------------
There has been some demand for a "formula" for easily calculating the final
size of a USERS.INF file given the known quantities of 1) number of
conferences, 2) size of TPAs and 3) number of users. The following formula
can be used for that purpose:
(( (Conf - 40) * 5 ) )
(( --------------- + (Conf - 40) * 4 + (Conf * TpaDyn) ) + TpaStat ) * Users
(( 8 ) )
Conf = the number of conferences on the system
TpaDyn = the size of all dynamic TPA allocations
TpaStat = the size of all static TPA allocations
Users = the number of users in the system
An example calculation for a system with 1000 conferences and QMAIL4
installed with 2000 users would be:
(( (1000 - 40) * 5 ) )
(( --------------- + (1000 - 40) * 4 + (1000 * 1) ) + 256 ) * 2000 =
(( 8 ) )
(( (960) * 5 ) )
(( --------- + (960) * 4 + 1000 ) + 256 ) * 2000 =
(( 8 ) )
(( 4800 ) )
(( ----- + 3840 + 1000 ) + 256 ) * 2000 =
(( 8 ) )
( 600 + 3840 + 1000 + 256 ) * 2000 =
5696 * 2000 =
11,392,000 (plus a small amount of overhead for TPA headers and such)
That's a fairly large file but for 1000 conferences and 2000 users it's quite
understandable. Smaller numbers of users and/or conferences will yield much
smaller figures. Of all of the allocations the biggest one is the Last
Message Read pointers which are 4 bytes in size for every conference. Given
the above example the LMR pointers make up 3840 bytes of the total 5696 bytes
per user.
USERS.SYS FILE LAYOUT
---------------------
The structure of the USERS.SYS file is as follows:
1) A header record describing what is contained in the file
2) A fixed-size user record with PCBoard specific data fields
3) Last Message Read pointers for conferences
4) Bit Map fields for conferences (registered, expired, scanned, etc)
5) The Third Party Application fixed record
6) The Third Party Application conference records
The following C structures are used to implement the above layout:
USERS.SYS HEADER STRUCTURE
--------------------------
NOTE: type "bool" is a character field (i.e. 1 byte in size) with a non-zero
value meaning TRUE and zero meaning FALSE.
typedef struct {
unsigned Version; PCBoard version number (i.e. 1500)
long RecNo; Record number from USER's file
unsigned SizeOfRec; Size of "fixed" user record (current size)
unsigned NumOfAreas; Number of conference areas (Main=1 thru 65535)
unsigned NumOfBitFields; Number of Bit Map fields for conferences
unsigned SizeOfBitFields; Size of each Bit Map field
char AppName[15]; Name of the Third Party Application (if any)
unsigned AppVersion; Version number for the application (if any)
unsigned AppSizeOfRec; Size of a "fixed length" record (if any)
unsigned AppSizeOfConfRec; Size of each conference record (if any)
long AppRecOffset; Offset of AppRec into USERS.INF record (if any)
bool Updated; TRUE if the USERS.SYS file has been updated
} syshdrtype;
USERS.SYS FIXED USER RECORD STRUCTURES
--------------------------------------
typedef struct { Bit packed flags in the users file
int Dirty :1; Dirty Flag (meaning file has been updated)
int MsgClear :1; User's choice for screen clear after messages
int HasMail :1; Indicates if NEW mail has been left for user
int DontAskFSE :1; Don't ask for if FSE should be used
int FSEDefault :1; Default to FSE
int ScrollMsgBody:1; Scroll message body when display messages
int ShortHeader :1; Display short message headers
int WideEditor :1; Use wide (79-column) message editor
} packedbyte;
typedef struct { Bit packed flags in the users file
int UnAvailable:1; Chat Status (Unavailable if bit is set)
| int SingleLines:1; Use SHORT File Descriptions
int Reserved:6; RESERVED! DO NO USE THESE BITS
} packedbyte2;
typedef struct { DOS format for bit packed date fields
int Day :5; 5 bit integer representing the Day
int Month :4; 4 bit integer representing the Month
int Year :7; 7 bit integer representing the Year MINUS 80
} datetype;
typedef struct {
char Street[2][51]; 2 NULL-terminated strings for street address
char City[26]; A NULL-terminated string for city
char State[11]; A NULL-terminated string for state
char Zip[11]; A NULL-terminated string for zip
char Country[16]; A NULL-terminated string for country
} addresstypez;
typedef struct {
char Previous[3][13]; 3 NULL-terminated strings for last 3 passwords
unsigned LastChange; Date of last password change
unsigned TimesChanged; Number of times password has been changed
unsigned ExpireDate; Expiration date of current password
} passwordtypez;
typedef struct {
unsigned FirstDateOn; First date on, in julian date format
unsigned NumSysopPages; Number of times caller paged the sysop
unsigned NumGroupChats; Number of times caller entered group chat
unsigned NumComments; Number of times caller left comment to sysop
unsigned Num300; Number of times caller was on a 300 bps
unsigned Num1200; Number of times caller was on a 1200 bps
unsigned Num2400; Number of times caller was on a 2400 bps
unsigned Num9600; Number of times caller was on a 9600 bps
unsigned Num14400; Number of times caller was on a 14400+ bps
unsigned NumSecViol; Number of security violations committed
unsigned NumNotReg; Number of attempts to join un-reg conference
unsigned NumReachDnldLim; Number of times download limit was reached
unsigned NumFileNotFound; Number of times download file was not found
unsigned NumPwrdErrors; Number of times entered password incorrectly
unsigned NumVerifyErrors; Number of times upload verification failed
} callerstattype;
typedef struct {
char Line[5][61]; 5 NULL-terminated strings for notes on caller
} notestypez;
typedef struct {
double StartingBalance; Starting Balance
double StartThisSession; Balance at login of current session
double DebitCall; Charges for calls made to the system
double DebitTime; Charges for time spent online
double DebitMsgRead; Charges for messages read
double DebitMsgReadCapture; Charges for messages captured
double DebitMsgWrite; Charges for messages written
double DebitMsgWriteEchoed; Charges for messages written (echoed)
double DebitMsgWritePrivate; Charges for messages written (private)
double DebitDownloadFile; Charges for files downloaded
double DebitDownloadBytes; Charges for bytes downloaded
double DebitGroupChat; Charges for time spent in group chat
double DebitTPU; Charges for third party utility usage
double DebitSpecial; Charges made via PPEs
double CreditUploadFile; Payback for files uploaded
double CreditUploadBytes; Payback for bytes uploaded
double CreditSpecial; Packback made via PPEs
char DropSecLevel; Security level on empty/negative balance
} accounttype;
typedef struct {
unsigned MaxMsgs; Maximum messages desired in QWK packet
unsigned MaxMsgsPerConf; Maximum messages per conference
long PersonalAttachLimit; Attach limit on personal messages
long PublicAttachLimit; Attach limit on public (non-personal) msgs
char Reserved[18];
} qwkconfigtype;
typedef struct {
char Name[26]; Name (NULL terminated)
char City[25]; City (NULL terminated)
char Password[13]; Password (NULL terminated)
char BusDataPhone[14]; Business or Data Phone (NULL terminated)
char HomeVoicePhone[14]; Home or Voice Phone (NULL terminated)
unsigned LastDateOn; Julian date for the Last Date On
char LastTimeOn[6]; Last Time On (NULL Terminated)
bool ExpertMode; 1=Expert, 0=Novice
char Protocol; Protocol (A thru Z)
packedbyte PackedFlags; Bit packed flags
datetype DateLastDirRead; Date for Last DIR Scan (most recent file)
int SecurityLevel; Security Level
unsigned NumTimesOn; Number of times the caller has connected
char PageLen; Page Length when display data on the screen
unsigned NumUploads; Total number of FILES uploaded
unsigned NumDownloads; Total number of FILES downloaded
long DailyDnldBytes; Number of BYTES downloaded so far today
char UserComment[31]; Comment field #1 (NULL terminated)
char SysopComment[31]; Comment field #1 (NULL terminated)
int ElapsedTimeOn; Number of minutes online
unsigned RegExpDate; Julian date for Registration Expiration Date
int ExpSecurityLevel; Expired Security Level
unsigned LastConference; Number of the conference the caller was in
| long ulTotDnldBytes; Total number of BYTES downloaded (no longer used - see TotDnldBytes below)
| long ulTotUpldBytes; Total number of BYTES uploaded (no longer used - see TotUpldBytes below)
bool DeleteFlag; 1=delete this record, 0=keep
long RecNum; Record Number in USERS.INF file
packedbyte2 Flags; More bit packed flags
char Reserved[8]; Bytes 390-397 from the USERS file
long MsgsRead; Number of messages the user has read in PCB
long MsgsLeft; Number of messages the user has left in PCB
bool AliasSupport; TRUE if Alias PSA installed
char Alias[26]; Chosen Alias, if AliasSupport is TRUE
bool AddressSupport; TRUE if Address PSA installed
addresstypez Address; Address information, if AddressSupport is TRUE
bool PasswordSupport; TRUE if Password PSA installed
passwordtypez PwrdHistory; Password History, if PasswordSupport is TRUE
bool VerifySupport; TRUE if Verify PSA installed
char Verify[26]; Verification Info, if VerifySupport is TRUE
bool StatsSupport; TRUE if Caller Stats PSA installed
callerstattype Stats; Caller Stats, if StatsSupport is TRUE
bool NotesSupport; TRUE if Notes PSA installed
notestypez Notes; Notes about caller, if NotesSupport is TRUE
bool AccountSupport; TRUE if Accounting PSA installed
accounttype Account; Accounting values, if AccountSupport is TRUE
bool QwkSupport; TRUE if QWK/Net PSA installed
qwkconfigtype QwkConfig; QWK/Net values, if QwkSupport is TRUE
| double TotDnldBytes; "Live data" stored in IEEE Double format (replaces ulTotDnldBytes)
| double TotUpldBytes; "Live data" stored in IEEE Double format (replaces ulTotUpldBytes)
} userrectype;
CHANGES FOR V15.0
-----------------
The fields near the end of the userrectype, from AliasSupport to Notes,
are new for v15.0. This means that the record size has GROWN. Those
applications which did not read the record size out of the header and jump
over any growth in the record size will fail.
However, version 15.0 allows you to set the USERS.SYS setting in DOORS.LST
to either Y or O. Setting it to Y tells PCBoard to create a native users.sys
file. Setting it to 1 tells PCBoard to create the 'old' format .. that which
was used by PCBoard v14.5a. This means that the additional information at
the end of the record will not be included.
We recommend that you update your applications to properly deal with the
variable sized records so that they can be used with both v14.5a and v15.0
users.sys files.
CHANGES FOR V15.2
-----------------
Once again, the USERS.SYS structure has GROWN. The four new fields for
version 15.2 are AccountSupport, Account, QwkSupport and QwkConfig.
To obtain a v15.0 format USERS.SYS file, use the number 2 inside DOORS.LST
under the USERS.SYS header. A Y means create a default format (v15.2),
1 means to create a v14.5a format, and 2 means to create a v15.0 format.
To ensure compatibility with all versions of PCBoard, you should ensure that
your software reads the header at the top of the USERS.INF file to determine
how big the structure is, then only read as much as your program knows
about, and also to determine how many bit fields there are since v15.2 has
one more bit field than v14.5 and v15.0 had.
LAST MESSAGE READ POINTERS
--------------------------
A LONG integer is used for each conference. Therefore you must know the
number of conference areas (syshdrtype.NumOfAreas) to determine how many
long integers there are in the file (remember that the MAIN BOARD counts
as one conference area).
BIT MAPPED FIELDS
-----------------
A bit mapped field is nothing more than a string of bytes which when held
together can be searched to see if a specific BIT is turned on or off.
You should read the header record syshdrtype.NumOfBitFields to determine
exactly how many bit fields there are in case a new release includes any
new fields (which you may skip over if you don't need them).
There are currently 8 of these fields and they are in the following order:
1) Registered in Conference
2) Expired Registered in Conference (same as above but used when expired)
3) User Scan in Conference (user preference for scanning conferences)
4) Conference Sysop (user gets Sysop Privileges while in conference)
5) Conference Mail (user has mail waiting in conference)
6) Conference Joined (user has already joined this conference today)
7) Conference Scanned (user has already scanned this conference today)
8) Conferences in which Net Status is available to th caller
The actual size of each of these fields is given to you in the header
record syshdrtype.SizeOfBitFields. You don't need to know this - but the
actual calculation of the size by PCBoard is made using the following
formula:
ConfByteLen = (NumAreas / 8) + ((NumAreas % 8) != 0 ? 1 : 0);
if (ConfByteLen < 5)
ConfByteLen = 5;
Basically, it allocates only the number of BYTES necessary to hold the
number of bits required for all of the conferences defined. A minimum of
FIVE bytes are used due to PCBoard v14.0's conference definition of 40
conference areas.
In other words, if you have only one conference there will be FIVE bytes
used due to v14.0's file layout requirements. If you have 100 conferences
then there will be 13 bytes used (with 4 bits going unused).
As you can see - bit mapped fields become almost a necessity with the fact
that there are currently 7 fields and a system may have as many as 65536
conferences (which if it weren't for bit mapped fields could prove to be a
very BIG file!). With all 7 fields a system with 1024 conferences uses up
only 896 bytes - which if one byte per flag were used could have taken up
as much as 7168 bytes.
CALCULATING THE JULIAN DATE VALUES
----------------------------------
The following calculations are used to calculate the LAST DATE ON and the
EXPIRATION DATE fields .. it is a julian date calculation which is used so
that arithmetic performed on the date value itself will result in another
valid date. In other words, "date + 365" equals a 365 days in the future.
int Days[12] = {0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334};
date = 36525L * Year;
if ((date % 100) == 0 && Month < 3)
date--;
date = (date - (1900 * 36525)) / 100;
date += Day + Days[Month-1];
Converting the julian date back into month, day and year values is a bit
trickier but is typically only done when displaying the date to the user or
storing it in the USERS file in "mmddyy" format. The following calculations
can be used to convert the date back into the month, day and year components:
int Days[2][12] = {0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334,
0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335};
Year = (100 * Date) / 36525;
Temp = Year * 36525L
Date -= Temp / 100;
if (Temp % 100 == 0) {
Date++;
Leap = 1;
} else Leap = 0;
for (Month = Counter = 0; Counter < 12; Counter++)
if (Days[Leap][Counter] < Date)
Month = Counter;
Day = JD - Days[Leap][Month];
THIRD PARTY APPLICATION RECORD
------------------------------
The Third Party Application record is used to hold information about the
USER which is specific to the application. PCBoard copies this information
out of the USERS.INF file into the USERS.SYS file and then copies it back
upon reloading the software. The advantage to letting PCBoard handle the
application needs is that as new users are added to the USERS file the
Third Party application records are created inside the USERS.INF file at
the same time. And when a user is removed from the USERS file they are
also removed from the USERS.INF file at the same time (while third party
records are also being removed).
The Third Party Application record is written in the USERS.SYS file
directly after the PCBoard Bit Map Fields.
If a there are no installed Third Party Applications (or none which
required a user record) then the USERS.SYS file will end with the Bit
Mapped Fields described above.
The way that PCBoard knows which Third Party Application record should be
appended to the USERS.SYS file is by the KEYWORD used by the caller to
invoke the application.
HANDLING THE USERS.SYS FILE
---------------------------
The following information is in reference to how PCBoard expects the
USERS.SYS file to be handled by Third Party Applications.
The USERS.SYS file is created as PCBoard is dropping to DOS and contains
what is basically a 'memory dump' of the values that PCBoard had in memory
at the time the caller dropped to DOS.
On returning from DOS PCBoard will check to see if a USERS.SYS file is in the
\PCB directory REGARDLESS of whether or not a PCBOARD.SYS file existed or
indicated that a caller was online.
If the Updated flag is set to TRUE (in this case the value must be a byte
value of 1 - no other value will be used to indicate TRUE so as to avoid
accidently specifying a TRUE response) then PCBoard will read in the rest
of the USERS.SYS file and update the USERS and USERS.INF files based on the
contents of the USERS.SYS file overwriting whatever previous values may have
been there.
If the Updated flag is set to FALSE (the default) then it is assumed that
the TPA may have updated the USERS file directly (in the case of existing
v14.0 compatible programs) or that no modification was required.
If the TPA allows the caller to hang up then it should clear the PCBOARD.SYS
file so that PCBoard will recycle. PCBoard will still read the USERS.SYS
file which will indicate that a caller was, in fact, online and if the
Updated flag was set then it will still update the USERS and USERS.INF files.
If the TPA updates the number of uploads, number of downloads or number of
messages left fields in USERS.SYS then PCBoard will properly determine that
such activity occured outside of the PCBoard environment and it will
properly update these statistics on the CALLWAITING screen without the use
of the PCBSTATS.EXE program.